Guide FAQ

Hi guys, in this lecture I’m going to elaborate a little bit more on the nature of this course, an ‘FAQ’ of sorts.

“Why doesn’t this guide cover sets, dicts, tuples?”

I’ve left out lots of things for a variety of reasons, the main three reasons being:

I do not have an infinite amount of time to spend on this project.
Syntax discussion is, though necessary, really boring to teach.
You must learn to think for yourselves!

Every time I increase the ‘scope’ of this project ‘quality’ is going to suffer; more lectures means more typos and bugs to catch with less time (per lecture) to catch them in!

And then there is the third (and most important) point; programming is about self-learning as opposed to being spoon-fed material. On numerous occasions throughout this guide I will encourage you to learn for yourselves, my job is to give you a set of tools to teach yourself with!

In short, this guide was never intended to be fully comprehensive and if you find yourself wanting to know how ‘X’ works (e.g. Sets, Tuples, Dicts) then the answer is merely a google away.

“What is the 'Zen of Python' and why should I care?”



In [1]:

    
import this









    



The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

The Zen of Python is a poem by Tim Peters, each line of which expresses something fundamental about the nature/design of Python. When I started to write this guide from very early on I knew I wanted to teach more than just syntax (anyone can do that), I wanted to write a guide that also instilled some of Python’s philosophy and ethos, without the discussion turning into abstract/pretentious drivel. Such discussion also had to be suitable for beginners as well.

In the end, I felt that the covering the ‘Zen of Python’ helps achieve these aims succinctly. By the end of this guide you should be able to understand most of what Tim Peter’s was waffling on about!

“This guide is really good, can I use it?”

I’m pretty much okay with anyone taking this body of work and doing whatever they want with it (that’s why I released it with an “MIT” license). So long as you give credit and don’t try to sell it for a profit it I don’t really care what you do.

“This guide sucks, this is wrong, that is wrong …”

Then please give me your suggestions for improvement. :)

"Why did you write this guide?"

Why? Why anything?

I guess there are two main reasons why I started this guide:

I enjoy teaching
I thought a big shiny project on Github might get me a job.

Personally I've been trying to get an entry level software job for about six months now, 40 applications a month and only two telephone interviews to show for it. I guess being a 29 year old dude with no relevant experience (or a computer science degree) probably means my CV doesn't really get past the "HR filter".

When I started writing this guide I did so with the hope that maybe-- just maybe-- it would help get me a foot in the door, so to speak. Time will tell I guess.

UPDATE JAN 2020

I wrote the paragraph above just about three years ago. I kindof abandoned this guide and have only recently come back to it.

Its perhaps worth pointing out that I did in fact end up landing a junior developer job at a small medical start-up writing mostly C# and Python. So now that I am older and wiser I've decided to update this guide to better reflect how I feel about code nowadays.

Anyway, I think I can say with hindsight that writing this guide probably wasn't the best use of my time; I had this idea that it would be a cool project to show potential employers what I could do, but I don't think they cared, or even looked at it. I probably would have been better off solving algorithms puzzles all day. Oh well, we live and we learn.



In [ ]: